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Abstract 

Over  the  last  few  years,  experiences  in  naval  coalition  force  activities  have  indicated  a 
considerable  shortfall  in  interoperability  between  participants.  This  has  been  detrimental 
to  their  overall  capability  and  reduced  their  effectiveness.  The  problems  are  associated 
not  only  with  the  technical  differences  between  the  participating  platforms  but  also  with 
the  lack  of  understanding  of  how  to  ‘function’  as  a  network  centric  coalition  task  force. 
The  latter  being  caused  by  the  limited  experience  of  working  in  such  an  environment,  due 
to  their  limited  occurrence,  and  also  the  cost  of  running  any  large  scale  exercises  to 
address  the  basic  problems.  A  collaborative  venture  has  been  underway  for  18  months 
between  UK  and  US  naval  research  groups  where  an  encrypted  link  is  being  used  for  the 
network  connectivity  to  provide  a  suitable  research  environment  to  investigate  the 
problems.  The  objective  is  to  address  such  areas  as  data  requirements,  management  and 
filtering  along  with  the  necessary  control  strategies  essential  for  effective  interoperability 
in  a  networked  coalition  force.  As  well  as  gaining  experience  in  areas  that  can  be 
transferred  onto  operational  systems,  the  four  year  program  should  provide  some 
yardstick  for  measurement  of  interoperability  and  whether  there  is  an  improvement  in 
technical  capability  or,  perhaps,  show  that  coalition  force  activity  is  primarily  a  political 
requirement. 

Background 

Experiences  in  the  Gulf  War  and  during  the  Kosovo  conflict  have  highlighted  the 
problems  of  multi-nation  naval  task  forces  working  together  in  an  efficient  co-ordinated 
way.  Even  though  each  participating  member  has  some  level  of  technological  support  at 
the  communications  and  combat  system  level,  the  level  for  communications  and  data 
exchange  has  been  that  of  manual  transfer  of  paper  copies  or  joint  presence  of 
representatives  from  each  unit  in  one  physical  location.  The  problem  has  been  the 
inability  of  these  systems  to  exchange  meaningful  information  arising  partially  due  to  the 
differing  technologies  which  are  present  in  the  participating  platforms  but  also  to  the 
different  ways  in  which  data  is  interpreted  and  the  meaning  of  the  information  generated 
from  it.  Expressions  such  as  ‘drowning  in  data  and  starved  of  information’  and  the 
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comment  that  ‘knowledge  superiority  requires  information  with  the  appropriate  latency 
and  fidelity’  are  the  basic  statements  on  the  problem  and  these  have  been  made  by  those 
who  were  in  charge  during  the  conflicts  mentioned  such  as  Admiral  Stone,  Naval  Task 
Force  Commander  off  Kosovo. 

There  has  been  an  increased  emphasis  on  the  adoption  of  a  Network  Centric  approach 
and  information  integration  in  military  task  forces  with  both  the  platform  level  and  task 
force  command  requiring  a  fused  view  of  the  joint  “battle  space”,  the  term  which  has  now 
replaced  “battle  field”  as  more  representative  of  the  environment  in  which  the  operations 
take  place.  As  was  pointed  out  by  US  Admiral  Jay  Johnson  the  move  to  Network  Centric 
Warfare  is  a  fundamental  shift  away  from  platform-centric  thinking.  It  will  require 
changes  to  organisational  structures  and  doctrine  that  will  lead  to  the  development  of  new 
tactics  and  operational  procedures.  The  need  for  effective  battle  force  interoperability 
and  painful  experiences  in  the  area,  have  given  rise  to  US  initiatives  such  as  the 
Distributed  Engineering  Plant  (DEP)  but  they  are  basically  addressing  single  nation 
issues  in  the  area,  between  systems  of  comparable  technologies  with  similar  command 
structures  and  the  same  interpretation  of  data  into  information.  The  need  to  operate 
effectively  as  part  of  a  coalition  force  will  require  some  modification  of  long  held  notions 
about  command  and  control,  particularly  the  principle  of  the  unity  of  command  and  the 
ability  not  only  to  send  out  data  but  to  transform  it  into  meaningful  information.  The  need 
is  for  delivery  of  the  right  amount  of  the  right  information  to  the  right  place  at  the  right 
time  in  the  right  format  in  a  network-centric  warfare  environment  to  increase  the 
effectiveness  of  the  participating  units. 

Recently,  as  part  of  an  information  exchange  between  the  US  staff  at  what  is  now 
NAVSEA  Newport  and  researchers  at  the  new  UK  MoD  organisation,  DSTL  at  the  Land 
Based  Test  Site  in  Portsmouth,  consideration  has  been  given  to  how  best  to  address  the 
problems  at  the  multi-national  level.  The  simple  answer  of  bringing  representative 
vessels  of  both  nations  together  to  carry  out  an  exercise  and  hoping  to  resolve  the 
numerous  problems  was  never  on,  mainly  due  to  the  cost  of  using  the  actual  operational 
platforms  (the  estimated  combined  costs  using  actual  platforms  exceeds  $500,000  per 
day).  Thus,  the  approach  adopted  derives  from  prior  experiences  and  investments  by 
both  countries  in  the  technologies  adopted  in  support  of  Open  System  Architectures, 
Interoperability  Test-beds,  and  Naval  Combat  System  Engineering  in  such  programmes 
as  the  New  Attack  Submarine  (NSSN  CIT  &  WAIF)  and  UK  CSTDF/POST/CSI  research 
programmes  with  the  opportunity  being  taken  to  join  their  respective  test  beds  via  an 
appropriate  encrypted  link. 

This  is  allowing  us,  using  basic  commercial  communications  and  the  necessary 
encryption  equipment,  to  experiment  with  two  combat  systems  exchanging  data  using  a 
common  scenario  under  controlled  conditions.  While,  from  the  operational  point  of  view 
our  scenario  is  slightly  unusual,  the  likelihood  of  a  US  submarine  and  a  UK  surface 
vessel  jointly  prosecuting  a  mission  is  remote,  it  does  provide  for  a  set  of  conditions 
which  are  very  relevant  to  the  coalition  network  situation.  The  data  transfers  will  not  be 
continuous  and  the  tactical  pictures  on  the  two  systems  will  be  considerably  different, 
which  is  exactly  the  situation  that  any  new  vessel  joining  a  coalition  task  force  network 


would  encounter.  The  work  so  far  has  concentrated  on  the  establishment  of  the  basic 
capability  in  terms  of  the  network  and  the  support  software  with  both  commercial 
products  and  DoD  tools  being  evaluated  in  the  software  area. 


Support  Tools 

One  of  the  tools  used  during  the  first  stage  of  the  collaboration  has  been  Odyssey 
Collaborative  System  (OCS).  This  product  derived  from  investments  by  ONR.  It 
supports  applications  that  make  use  of  interactive  video  conferencing,  and  as  our 
collaboration  required  an  extensive  amount  of  video  teleconferencing  connectivity  this 
was  an  obvious  tool  to  try.  To  facilitate  the  assessment  of  Odyssey  the  UK  and  US  sides 
agreed  that  the  US  side  would  install  the  Server-side  while  the  UK  installed  the  Client- 
side  of  Odyssey.  The  installation  was  a  non-trivial  task.  The  initial  installation  was 
attempted  on  a  Windows  NT4  machine  but  was  troublesome  so  after  advice  from  our  US 
colleagues  an  attempt  was  made  to  install  on  Windows  2000,  which  the  US  had  been 
successful  in  achieving.  This  also  failed,  so  NT4  was  attempted  again  and  after  much 
lower  level  tweaking  of  the  configuration  and  batch  files  it  succeeded  this  time.  With  the 
UK  side  being  the  client  to  the  US’s  server  the  geographical  split  then  brought  the 
physical  networking  infrastructure  to  the  fore.  After  further  basing  with  US  counterparts, 
the  US  Odyssey  client  came  up  to  a  level  at  which  we  could  start  using  the  tool. 

Experiences  with  Odyssey 

As  the  UK  side  was  set  as  the  client  it  was  always  necessary  to  have  the  US  side’s  server 
up  and  running  before  anything  could  be  done.  This  was  rarely  if  ever  a  problem. 
However,  the  responses  from  the  server  seemed  to  come  at  glacial  speed.  At  some  points 
during  the  OCS  interaction  the  whole  system  would  lock  up  and  no  responses  could  be 
got  from  the  server.  This  may  have  been  due  to  timeouts  built  into  the  system,  but  at  the 
time  there  was  no  way  of  knowing.  The  situation  invariably  came  about  from  the  way  in 
which  interaction  with  Odyssey  took  place.  One  of  the  impressive  features  of  Odyssey  is 
the  ability  to  create  and  define  objects  and  rooms.  In  collaboration  with  our  US 
colleagues  a  set  of  buildings  was  created  to  reflect  platforms  (frigates,  submarines,  etc.) 
and  our  respective  labs.  Within  those  rooms,  subsidiary  areas  such  as  operations  rooms, 
sonar  rooms,  lab  rooms  and  so  on  were  created  into  which  documents  could  be  made 
available  and  where  virtual  ‘meetings’  with  people  took  place.  It  was  hoped  that  it  would 
be  possible  to  ‘move’  around  within  these  rooms,  retrieve  and  view  objects  such  as 
documents,  and  arrange  private  or  public  chats  with  team  members  determined  to  be 
‘present’.  All  of  this  interaction  was  to  be  carried  out  using  Odyssey’s  point  and  click 
interface.  The  reality  was,  however,  not  initially  encouraging. 

The  system  response  time  was  inadequate.  For  example,  one  would  click  on  a  room  to 
‘teleport’  oneself  into  it  and  it  would  be  minutes  before  the  room  was  updated  to  reflect 
one’s  presence  in  that  room.  After  discussing  with  US  counterparts  who  assured  us  they 
had  had  no  similar  problems,  it  was  surmised  that  the  problem  must  lie  with  the 
communications  network  to  the  US.  This  was  indeed  more  than  likely  as  was  obvious 
from  experiences  using  our  network  ‘link’  with  other  commercial  products  like 
NetMeeting.  Closer  examination  revealed  that  the  ISDN  connection  was  inexplicably 


dropping  channels  during  the  link-up.  Another  source  of  latency  may  also  have  been 
introduced  by  the  network  hardware.  The  problem  was  to  then  find  a  way  of  assessing 
Odyssey  in  the  absence  of  reliably  fast  communications  links. 

It  was  decided  to  remove  the  need  for  networking  in  a  geographically  dispersed 
environment.  A  copy  of  the  then  latest  Odyssey  software  for  both  the  Client-side  and  the 
Server-side  was  installed  on  two  different  machines  in  the  UK.  The  installation  was 
eventually  managed  with  one  NT4  machine  set  as  a  client  and  another  as  the  server. 
With  this  arrangement  it  was  possible  to  get  it  working.  It  became  possible  to  control  the 
creating  of  rooms,  which  initially  was  only  the  preserve  of  the  US’s  server  side  of 
Odyssey.  The  response  from  the  system  was  very  much  improved  and  navigation 
relatively  easy,  moving  from  room  to  room,  carrying  out  private  conversations  or  open 
discussions. 

Odyssey  itself  is  a  very  comprehensive  tool  with  many  desirable  features  that  are  not 
readily  available  on  many  similar  commercial  packages.  It  is  more  of  a  ‘virtual  space’ 
environment  than  merely  a  collaboration  tool,  the  latter  for  our  needs  focusing  more  on 
knowledge  management.  Of  the  more  impressive  features  is  its  user-customisability  to 
reflect  the  geographical  set-up  of  the  environment  where  teams  are  located.  This  has  the 
advantage  of  adding  some  realism,  albeit  limited.  The  virtual  presence  of  other  team 
members  on  screen  and  being  able  to  notice  their  comings  and  goings  has  the  effect  of 
letting  one  know  the  possibility  of  instant  problem  or  knowledge  sharing.  There  are 
additional  capabilities  that  would  be  desirable,  but  would  appear  to  have  been  overlooked 
in  the  current  version  of  the  Odyssey  system. 

Document  management  is  a  vital  part  of  working  in  teams.  It  is  the  main  means  by  which 
plans  are  updated,  revised  and  issued.  Read  and  write  permissions  are  good  as  controls 
on  documents  but  other  features  are  important.  For  example,  it  would  be  useful  to  have  a 
way  in  which  common  documents  being  written  could  be  controlled  in  such  a  way  that 
the  document  can  only  be  checked  out  by  one  person  at  a  time,  thus  protecting  them  from 
being  overwritten  when  two  people  work  on  the  same  document  simultaneously. 
Additionally,  facilitating  the  creation  of  private  and  public  versions  of  documents  would 
be  an  advantage.  There  are  more  document  management  features  that  are  needed  to  ease 
collaborative  work  and  we  await  the  next  revision  of  the  tool. 

Conclusions  Regarding  Odyssey 

Odyssey  has  some  excellent  features  as  a  tool  but  the  experiences  we  have  had  so  far 
indicate  that  its  maturity  is  a  still  at  a  low  level.  Specific  shortcomings  can  be 
summarized  as  follows: 

1.  It  is  rather  a  difficult  tool  to  install.  We  had  to  dive  into  the  internals,  changing  batch 
files  and  redirecting  paths. 

2.  The  response  times  suggest  that  a  geographically  dispersed  team  working 
collaboratively  would  have  difficulty  using  some  of  its  features  that  require  higher 
bandwidth. 


3  It  is  not  really  a  collaborative  tool  but  more  of  a  virtual  space  environment  where 
team  members  may  be  in  the  same  time  zone  and  therefore  more  dynamically 
interacting.  Collaboration  puts  more  emphasis  on  synchronisation  of  activities, 
avoiding  duplication  of  effort  when  working  on  the  same  subject,  and  the 
management  of  information. 

One  suggestion  that  we  would  make  is  to  investigate  modular  implementation  of  some  of 
the  features  of  the  system,  not  unlike  the  way  Enterprise  Resource  Planning  (ERP)  tools 
such  as  SAP  are  implemented,  where  a  subset  of  the  features  can  be  selected.  This  is 
achieved,  not  merely  by  disabling  a  particular  feature  or  module,  but  by  not  building  it 
into  the  implemented  system.  This  may  have  the  advantage  of  simplifying  and 
lightening  the  system  as  a  whole. 

Overall,  the  ideas  behind  the  tool  are  very  good  and  the  tool  would  be  suited  to  most 
activities  in  any  collaborative  environment,  which  requires  representation  of  different 
‘locations’,  which,  in  our  case,  are  naval  platforms. 

Operational  Aspects 

Moving  from  the  support  side  of  our  activities  to  the  operational  side  of  the  collaboration, 
a  common  scenario  has  been  generated  to  meet  the  needs  of  our  investigation.  As 
indicated  earlier,  the  scenario  may  not  reflect  the  normal  run  of  platform  interactions,  but 
it  envisages  a  joint  operation  in  response  to  terrorist  activities  and  involves  surface, 
subsurface  and  air  units  with  the  possibility  to  extend  the  action  into  other  domains  as 
needed  in  the  future.  The  complexity  of  the  operation  is  expandable  but  has  been  kept  at 
a  simplistic  level  at  present  while  the  problems  of  communications  and  synchronisation 
have  been  resolved  between  the  sim/stim  drivers  that  implement  the  scenario.  The  basic 
idea  is  that  sensor  data  is  being  processed  through  the  UK  surface  combat  data  fusion 
system  and  the  output  transmitted  to  the  US  subsurface  unit  at  the  appropriate  times,  and 
that  the  US  platform  is  providing  periodic  sonar  picture  updates  based  on  the  same 
sim/stim  program  to  enable  the  operational  task  to  be  executed.  This  raises  several  issues 
concerning  the  data,  which  is  being  exchanged. 

The  research  work  is  addressing  such  issues  as: 

•  data  requirements 

•  data  management  and  filtering 

•  data  structures  and  content 

•  control  strategies 

•  data  servers  vs.  datalinks 

Having  establish  the  initial  connectivity  and  the  passing  of  tactical  picture  data,  the  major 
effort  has  moved  on  to  investigate  the  formats  and  structure  of  information,  the 
information  architecture,  and  ways  for  both  sides  to  reach  an  agreement  on  their 
interpretation  of  that  information  within  their  own  environment.  There  is  no  point  in 
exchanging  data  that  adds  no  value.  Early  tests  are  being  used  to  identify  the  basic  levels 
that  are  acceptable  to  the  two  combat  systems  in  terms  of  enhancing  the  system  capability 


by  the  introduction  of  new  information,  but  at  the  same  time  not  overloading  it  with 
useless  (and  potentially  distracting)  information.  There  will  be  several  tests  in  this  area 
to  demonstrate  the  basic  capabilities  that  will  be  required  to  support  the  more  complex 
experiments. 

In  a  more  general  subject  area,  it  will  be  necessary  to  investigate  the  relationship  between 
a  subsurface  platform  and  surface  platform  and  the  transfer  of  information  between  them. 
It  will  be  necessary  to  investigate  the  use  of  current  datalinks  (Link- 11  and  Link- 16)  or 
other  message  formats  and  to  consider  whether  the  present  operational  procedures  are 
acceptable  in  the  new  network-centric  environment.  It  might  be  an  appropriate  time  to 
consider  how  best  to  handle  the  coalition  force  information  in  this  situation  as  distinct 
from  the  present  data  link  scenarios.  Although  existing  Link- 11  and  Link- 16  include 
some  subsurface  message  formats  they  have  been  used  little  to  date  and  the  possibility  of 
developing  some  form  of  Coalition  Data  Server  (CDS)  is  being  considered. 

Large  scale  information  transfer  involving  submarines  is  likely  to  be  performed  on  a 
spasmodic  basis,  enabled  only  when  a  submarine  is  in  contact  with  a  surface  platform. 
The  purpose  of  this  area  of  research  is  to  determine: 

•  The  effect  on  the  above  water  platform  of  integrating  such  spasmodic  and  time 
varying  information  from  a  submarine  into  the  rest  of  its  tactical  picture  involving 
organic  and  non-organic  wide  area  non-real  time  information. 

•  The  effect  on  the  under  water  platform  of  integrating  real  time  information  into  its 
picture  and  subsequent  handling  of  that  data  in  terms  of  staleness,  predictions  etc. 

The  effort  here  will  build  on  the  present  set  of  experiments,  looking  at  the  types  of 
information  that  could  be  exchanged  and  how  this  could  be  managed.  The  aim  at  this 
stage  will  be  to  compare  particularly  the  pictures  compiled  in  the  relevant  surface  and 
subsurface  platforms  as  time  progresses  without  refresh.  It  will  be  attempted  to 
determine  whether  the  degree  of  drift  between  the  actual  and  perceived  positions 
outweighs  the  initial  transfer  of  information  and  whether  better  staleness  or  prediction 
measures  could  be  used  to  improve  the  pictures.  It  will  also  allow  some  assessment  of 
the  best  options  for  interoperation  between  the  surface  and  subsurface  platforms  in  terms 
of  the  procedures  covering  such  aspects  as  frequency  of  contact  and  amount  and  type  of 
data  exchanged. 

The  follow  on  from  this  is  to  provide  the  ability  to  investigate  the  remote  use  of  sensors 
and  weapons  such  as  EW,  sonar,  torpedoes  and  missiles  between  coalition  platforms, 
initially  starting  with  the  sub  to  surface  link  and  then  expanding  to  the  different  platforms 
in  the  network.  The  network  at  this  stage  should  be  capable  of  allowing  land  and  air 
platforms  to  be  integrated  as  part  of  the  environment  and  the  full  coalition  battle  space 
scenario  addressed  building  on  the  experience  gained  from  the  earlier  investigations  and 
experiments.  It  will  also  provide  the  ability  to  investigate  the  remote  use  of  sensors  and 
weapons  such  as  radar,  IR,  EW,  sonar,  torpedoes  and  missiles  between  coalition 
platforms,  initially  starting  with  the  sub  to  surface  link  and  then  expanding  to  the 
different  platforms  in  the  network.  The  concept  here  is  that  the  network  will  provide  the 
ability  to  decouple  the  specific  sensor  from  the  platform  on  which  it  resides  and  to  make 


it  one  of  the  sensors  available  on  the  task  force  network  and  accessible  to  anyone  who  has 
the  necessary  access  to  and  need  for  a  source  of  data.  Not  only  does  this  enable  the 
actual  range  over  which  a  sensor’s  data  is  contributing  to  be  significantly  increased  but  it 
also  means  that  participating  platforms  have  access  to  the  ‘best’  sensor  available  within 
the  task  force  thereby  increasing  the  quality  of  the  data  available. 

It  will,  however,  raise  many  questions  of  control  and  authority. 

Once  the  US  network  has  been  extended  to  link  to  other  US  surface  platform  test  bed 
facilities  and  the  UK  end  has  a  similar  extended  capability,  issues  such  as  force  data 
fusion  across  the  coalition  surface  and  subsurface  platforms  can  be  investigated.  This 
opens  up  the  possibility  for  investigating  the  factors  mentioned  earlier  in  the 
organisational  and  doctrine  areas: 

•  The  different  operating  characteristics  of  the  UK  and  US  navies, 

•  The  different  command  structures. 

•  The  different  interpretation  of  data  into  information  and  understanding 

•  How  to  operate  Network-Centric  Command  and  Control 

A  further  area  for  investigation  will  be  extending  the  experiences  gained  from  the 
investigations  into  the  spasmodic  type  of  interaction  to  see  if  any  of  the  lessons  learned 
can  be  used  in  setting  set  up  the  joining  and  leaving  procedures  for  a  platform  and  a  force 
network  in  terms  of  what  is  required  and  how  it  is  controlled. 

And  in  conjunction  with  these  issues  the  collaboration  is  looking  at  how  to  evaluate  the 
effectiveness  of  such  interoperability  between  combat  systems  and  lay  down  some  initial 
guidelines  for  how  this  type  of  coalition  network  might  be  operated,  what  the  procedures 
are  for  joining  and  leaving  a  network-centric  force  and  how  to  improve  the  capabilities  of 
the  platforms  involved  rather  than  just  “drowning  them  in  data”.  The  results  of  the 
collaboration  will  help  to  move  systems  up  through  the  information  domain  from  the  data 
level  to  the  situation  knowledge  level  and  thereby  increase  the  ability  to  understand  and 
assess  that  situation. 

Coalition  Data  server 

As  has  been  pointed  out,  any  task  force  battle  group  or  coalition  force  naval  operation 
requires  coordinated  communication  among  diverse  platforms  and  integration  of 
information  assets  for  success.  Additionally,  the  requirement  is  for  naval  combat  systems 
of  diverse  manufacture,  providing  different  views  of  the  battle  space  with  different  levels 
of  confidence  and  capability,  to  interact  effectively  and  flexibly  as  a  system  of  systems 
for  effective  mission  accomplishment. 

The  coalition  needs  expressed  above  distils  to  an  initial  aim,  which  is  to  transfer  data 
between  heterogeneous  platforms  with  the  minimum  of  the  human  intervention  required 
for  the  information  exchange.  The  proposal  is  to  adopt  a  flexible  architecture  to  facilitate 
current  as  well  as  future  requirements,  and  the  extensible  Markup  Language  (XML) 
provides  a  way  that  facilitates  one  machine’s  applications  to  interact  with  another  using  a 
common  human  readable  data  format.  The  intention  is  to  build  a  prototype  CDS  to 


incorporate  US  and  UK  coalition  applications  by  building  XML  parsers  and  generators 
for  each  application  and  to  use  the  Servers  as  the  bridge  (translator)  between  coalition 
data  and  application  specific  data  with  an  interactive  Java  CDS  viewer  with  read  and 
write  capability.  The  basic  aim  is  to  show  the  ability  of  the  CDS  to  make  data  available 
to  a  remote  platform. 

When  using  XML,  it  is  possible  for  a  system  to  receive  XML-tagged  data  from  another 
system,  and  the  other  can  receive  XML-tagged  data  from  the  first.  Neither  of  them  needs 
to  know  how  the  other's  system  is  organized.  If  another  partner  or  supplier  teams  up  with 
the  network,  there  is  no  need  to  write  code  to  exchange  data  with  their  system.  They  are 
simply  required  to  follow  the  document  rules  defined  in  the  schema. 

One  of  the  early  tasks  has  been  to  standardize  on  a  schema  to  define  coalition  data 
content.  An  XML  schema  defines  what  tags  can  go  in  your  document,  what  tags  can 
contain  other  tags,  the  number  and  sequence  of  the  tags,  the  attributes  the  tags  can  have, 
and  optionally,  the  values  those  attributes  can  have.  To  achieve  this,  the  data 
requirements  of  current  US  /  UK  applications  have  been  examined.  The  initial  sample  of 
data  messages  has  yielded  a  schema,  which,  although  not  complete,  serves  the  purposes 
for  exploring  the  concepts  identified  above. 

Effectiveness  of  Joint/ Coalition  Forces 

In  parallel  with  the  research  identified  above,  a  major  activity  during  this  work  must  be 
the  identification  of  measures  of  effectiveness  for  joint/coalition  force  activities.  While  it 
may  be  possible  to  exchange  information,  it  is  essential  that  there  is  some  means  of 
assessing  the  effectiveness  of  what  is  being  achieved.  This  will  need  to  take  into 
consideration  both  the  national  and  joint/coalition  requirements  and  to  what  level  the 
coalition  platform  systems  will  be  integrated  into  a  task  force  unit.  It  will  of  necessity 
not  only  address  the  technical  issues,  but  also  will  have  to  deal  with  the  command  and 
doctrinal  issues  that  will  arise. 

Summary 

The  adoption  of  an  early  integration  testing  approach  in  the  development  of  complex 
systems  has  proven  to  be  a  success.  In  fact,  the  U.  S.  Navy  has  since  embarked  on  the 
establishment  of  a  Distributed  Engineering  Plant  (DEP)  and  a  Collaborative  Engineering 
Environment  (CEE)  modelled  on  their  Wide  Area  Integration  Facility  (WAIF) 
experiences.  From  an  architectural  perspective,  the  development  issues  and  the 
operational  issues  are  seen  to  have  much  in  common  where  test  and  integration  are 
concerned.  This  approach  is  now  being  employed  at  the  joint/coalition  force  level  and  the 
avoidance  of  operational  problems  achievable  as  a  result  of  adopting  such  an  approach  is 
substantial. 

Taken  in  its  broadest  view,  interoperability  is  more  than  just  connectivity  and 
communications.  Its  import  goes  beyond  just  command  and  planning  activities  to 
embrace  real  time  sensor  data  integration  among  collaborating  platforms.  In  a  real  sense 
the  objective  is  a  virtual  combat  system  that  spans  platforms.  The  drive  for  interoperable 
combat  systems  is  a  natural  consequence  of  the  increasing  emphasis  on  information 
warfare,  of  the  increasing  reliance  on  joint  and  coalition  forces  to  achieve  military 


objectives,  of  the  increasing  reliance  on  commercial  technologies,  and  on  the  decreasing 
defense  acquisition  and  research  and  development  budgets.  Needing  or  desiring 
interoperability  is  not  the  same  as  achieving  it  however.  There  remains  much  to  do  to 
bring  about  the  interoperable  combat  systems  needed  for  success  in  the  era  of  network¬ 
centric  operations  and  information  warfare. 

As  we  seek  to  manage  an  information  landscape  that  is  more  comprehensive  and  diverse 
each  day,  it  is  important  to  guard  against  the  technological  imperative  to  do  things  merely 
because  we  can.  Access  to  all  information  all  of  the  time  is  not  the  optimal  design 
objective  for  combat  systems.  It  is  not  even  desirable.  We  must  also  guard  against  the 
tendency  to  confuse  technology  with  engineering.  Proper  use  of  technology  requires  that 
we  engineer  our  systems  with  careful  attention  to  architectural  issues.  There  remains 
plenty  of  work  to  do.  A  near-term  list  might  include: 


Identifying  the  consequences  of  interfacing  systems  designed  to  different  architectural 
standards 

Developing  measures  of  architectural  openness 

Overcoming  obstacles  to  wide-area  distribution  of  time  critical  sensor-to-shooter  loops 

Determining  the  extent  of  necessary  commonality  in  deployed  information 

infrastructure 

Understanding  and  coping  with  terminological  and  training  barriers  to  interoperable 
coalition  force  combat  systems 

Identification  of  an  appropriate  Combat  System  Interface  Profile  to  support 
interoperability 

Developing  criteria  for  managing  the  information  landscape 


The  bottom  line  objective  in  the  search  for  combat  systems  that  are  both  operable  and 
interoperable  must  never  be  lost  sight  of:  providing  the  right  amount  of  the  right 
information  to  the  right  place  at  the  right  time  in  the  right  format. 

The  experience  so  far  from  the  first  phase  has  validated  the  basic  tenet  that  the  problems 
under  investigation  are  not  simple.  In  order  for  two  similar,  yet  fundamentally  dissimilar, 
systems  to  work  together  a  common  understanding  is  required  of  the  terminology  and 
ways  in  which  tasks  are  carried  out.  The  learning  curve  is  steep  and  progress  at  times 
seems  slow,  but  at  least  the  problems  are  being  identified  and  resolved  before  the  real 
platforms,  and  the  related  costs  that  would  incur,  are  involved. 


